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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the protocol details for SMS over IP within the IP Multimedia (IM) Core Network (CN) 
subsystem based on the Session Initiation Protocol (SIP) and SIP Events as defined in 3GPP TS 24.229 [10]. 

Where possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP and SIP Events, either directly, or as modified by 3GPP TS 24.229 [10]. 

The present document is applicable to Application Servers (ASs) and User Equipment (UE) providing SMS over IP 
functionality. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

SM-over-IP sender: the A party that sends an SM using a SIP MESSAGE request including a vnd.3gpp.sms payload 
(introduced in 3GPP TS 23.140 [4]). 

SM-over-IP receiver: the B party that receives an SM encapsulated in the vnd.3gpp.sms payload of a SIP MESSAGE 
request. 

For the purposes of the present document, the following terms and definitions given in RFC 3261 [12] apply. 

Header 

Header field 

Method 

Request 

Response 

(SIP) transaction 

Status-code (see RFC 3261 [12], subclause 7.2) 

Tag (see RFC 3261 [12], subclause 19.3) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [2], 
subclauses 4.1.1.1 and 4a.7 apply: 

Call Session Control Function (CSCF) 
Home Subscriber Server (HSS) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.218 [6], 
subclause 3.1 apply: 

Filter criteria 
Initial filter criteria 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [7], 
subclauses 4.3.3.1, 4.3.6 and 4.6 apply: 

Interrogating-CSCF (I-CSCF) 
Public Service Identity (PSI) 
Proxy-CSCF (P-CSCF) 
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Serving-CSCF (S-CSCF) 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1], TS 23.040 [3] and the following 
apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if 
any, in TR 21.905 [1]. 

AS Application Server 

IP-SM-GW IP-Short-Message-Gateway 

4 Overview of SIVIS over IP functionality 

4.1 Introduction 

SMS over IP functionality provides the UE with the capability of sending traditional short messages over IMS network. 
The architecture for SMS is specified in 3GPP TS 23.040 [3] and for SMS over IP functionality in 3GPP TS 23.204 [5]. 

4.2 SMS over IP 

In order to guarantee SMS interoperability the SM-over-IP sender, the SM-over-IP receiver and the IP-SM-GW shall 
support encapsulation of RPDUs defined in 3GPP TS 24.011 [8], subclause 7.3. The SM-over-IP sender, the SM-over- 
IP receiver and the IP-SM-GW shall use the MIME type "application/vnd.3gpp.sms" for this purpose. 

4.3 Application utilisation of SMS over IP 

SMS over generic IP access can be used to support all applications and services that use SMS. 

4.4 SMS over IP and subscription without MSISDN 

When SMS over IP is to be delivered to a subscriber where the subscription profile does not contain an MSISDN, then 
there is a need for the IP-SM-GW to become aware of the IMSI during IMS registration for later correlation of short 
messages. In order to do so the IP-SM-GW derives the IMSI from the private user identity of the user that the UE 
includes in the REGISTER request at registration or if the private user identity is not available, derives the IMSI from 
the public user identity. 

3GPP TS 23.003 [22] defines the relationship between the private user identity and the IMSI and the relationship 
between the public user identity and the IMSI. 

5 SIP related procedures 

5.1 Introduction 

5.2 Functional entities 
5.2.1 User Equipment (UE) 

A UE may implement the role of an SM-over-IP sender (see subclause 5.3.1) or an SM-over-IP receiver (see 

subclause 5.3.2). A mechanism for the home operator to configure the UE to use SMS over IP is given in 

3GPP TS 24.167 [8A]. Additional parameters such as the PSI of the SC of the SM-over-IP sender can be obtained from 
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the UICC as per 3GPP TS 31.103 [18] and 3GPP TS 31.102 [19] if used or from the SIM as per 3GPP TS 51.011 [20] if 
used. 

NOTE: The capability of sending short messages over IP does not affect current limitations, thus the UE is 

limited to send at most one UE originated SM and to receive at most one UE terminated SM at a time. 

5.2.2 Application Server (AS) 

An AS may implement the role of an IP-SM-GW (see subclause 5.3.3). 

5.3 Roles 

5.3.1 SM-over-IP sender 

5.3.1.1 General 

In addition to the procedures specified in subclause 5.3.1, the SM-over-IP sender shall support the procedures specified 
in 3GPP TS 24.229 [10] appropriate to the functional entity in which the SM-over-IP sender is implemented. The SM- 
over-IP sender shall build and populate RP-DATA message, containing all the information that a mobile station 
submitting an SM according to 3GPP TS 24.011 [8] would place, for successful delivery. The SM-over-IP sender shall 
parse and interpret RP- DATA, RP-ACK and RP-ERROR messages, containing all the information that a mobile station 
receiving an SM according to 3GPP TS 24.01 1 [8] would see, in a SM submission or status report. 

5.3.1 .2 Submitting a short message 

When an SM-over-IP sender wants to submit an SM over IP, the SM-over-IP sender shall send a SIP MESSAGE 
request with the following information: 

a) the Request-URI, which shall contain the PSI of the SC of the SM-over-IP sender; 

NOTE 1 : The PSI of the SC can be SIP URI or tel URI based on operator policy. The PSI of the SC can be obtained 
using one of the following methods in the priority order listed below: 

1) provided by the user; 

2) if UICC is used, then: 

- if present in the ISIM, then the PSI of the SC is obtained from the EFpsisMsc in DF_TELECOM of 
the ISIM as per 3GPP TS 31.103 [18]; 

if not present on the ISIM, then the PSI of the SC is obtained from the EFpsbmsc in 
DF_TELECOM of the USIM as per 3GPP TS 31.102 [19]; or 

if neither present on the ISIM nor on the USIM, then the PSI of the SC contains the TS-Service- 
Centre-Address stored in the EFsmsp in DF_TELECOM as per 3GPP TS 31.102 [19]. If the PSI of 
the SC is based on the E. 164 number from the TS-Service-Centre-Address stored in the EFsmsp in 
DF_TELECOM then the URI constructed can be either a tel URI or a SIP URI (using the 
"user=phone" SIP URI parameter format). 

3) if SIM is used instead of UICC, then the PSI of the SC contains the TS-Service Centre Address stored 
in the EFsmsp in DF_TELECOM as per 3GPP TS 51.011 [20]. If the PSI of the SC is based on the 
E.164 number from the TS-Service-Centre- Address stored in the EFsmsp in DF_TELECOM then the 
URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter 
format); or 

4) if neither the UICC nor SIM is used, then how the PSI of the SC is configured and obtained is through 
means outside the scope of this specification. 

b) the From header, which shall contain a public user identity of the SM-over-IP sender; 
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NOTE 2: The IP-SM-GW will have to use an address of the SM-over-IP sender that the SC can process (i.e. an 
E.164 number). This address will come from a tel URI in a P-Asserted-Identity header (as defined in 
RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF. 

NOTE 3: The SM-over-IP sender has to store the Call-ID of the SIP MESSAGE request, so it can associate the 
appropriate SIP MESSAGE request including a submit report with it. 

c) the To header, which shall contain the PSI of the SC of the SM-over-IP sender; 

d) the Content-Type header, which shall contain "application/vnd.3gpp.sms"; and 

e) the body of the request shall contain an RP-DATA message as defined in 3GPP TS 24.01 1 [8], including the 
SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3]. 

NOTE 4: The address of the SC is included in the RP-DATA message content. The address of the SC included in 
the RP-DATA message content is stored in the EFsmsp in DF_TELECOM of the (U)SIM of the SM-over- 
IP sender. 

NOTE 5: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in 
the body of the SIP MESSAGE request. 

NOTE 6: Both the address of the SC and the PSI of the SC can be configured in the EFpskmsc in DF_TELECOM of 
the USIM and ISIM respectively using the USAT as per 3GPP TS 31.111 [21]. 

The SM-over-IP sender may request the SC to return the status of the submitted message. The support of status report 
capabilities is optional for the SC. 

When a SIP MESSAGE request including a submit report in the "vnd.3gpp.sms" payload is received, the SM-over-IP 
sender shall: 

if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request 
corresponds to a short message submitted by the SM-over-IP sender, generate a 200 (OK) SIP response 
according to RFC 3428 [14]. 

if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request 
does not correspond to a short message submitted by the SM-over-IP sender, a 488 (Not Acceptable here) SIP 
response according to RFC 3428 [14]. 

if SM-over-IP sender does not support In-Reply-To header usage, generate a 200 (OK) SIP response according 
to RFC 3428 [14]; and extract the payload encoded according to 3GPP TS 24.01 1 [8] for RP-ACK or RP- 
ERROR. 

5.3.1 .3 Receiving a status report 

When a SIP MESSAGE request including a status report in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP 
sender shall: 

- generate a SIP response according to RFC 3428 [14]; 

- extract the payload encoded according to 3GPP TS 24.01 1 [8] for RP-DATA; and 

create a delivery report for the status report as described in subclause 5.3.2.4. The content of the delivery report 
is defined in 3GPP TS 24.01 1 [8]. 

5.3.2 SM-over-IP receiver 
5.3.2.1 General 

In addition to the procedures specified in subclause 5.3.2, the SM-over-IP receiver shall support the procedures 
specified in 3GPP TS 24.229 [10] appropriate to the functional entity in which the SM-over-IP receiver is implemented. 
The SM-over-IP receiver shall build and populate RP-SMMA, RP-ACK, and RP -ERROR messages, containing all the 
information that a mobile station according to 3GPP TS 24.01 1 [8] would place, for a notification for availability of 
memory and a delivery report. The SM-over-IP receiver shall parse and interpret RP- DATA message, containing all the 
information that a mobile station receiving an SM according to 3GPP TS 24.01 1 [8] would see, in a SM delivery. 
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5.3.2.2 Registration 

On sending a REGISTER request, the SM-over-IP receiver shall indicate its capability to receive traditional short 
messages over IMS network by including a "+g.3gpp.smsip" parameter into the Contact header according to 
RFC 3840 [16]. 

5.3.2.3 Delivery of a short message 

When a SIP MESSAGE request including a short message in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP 
receiver shall: 

- generate a SIP response according to RFC 3428 [14]; 

- extract the payload encoded according to 3GPP TS 24.01 1 [8] for RP-DATA; and 

create a delivery report as described in subclause 5.3.2.4. The content of the report is defined in 

3GPPTS 24.011 [8]. 

5.3.2.4 Sending a delivery report 

When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP 
MESSAGE request with the following information: 

a) the Request-URI, which shall contain the IP-SM-GW; 

NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE 
request including the delivered short message. 

b) the From header, which shall contain a public user identity of the SM-over-IP receiver. 

c) the To header, which shall contain the IP-SM-GW; 

d) the In-Reply-To header which shall contain the Call-Id of the SIP MESSAGE request that was received in the 
received short message; 

e) the Content-Type header shall contain "application/vnd.3gpp.sms"; and 

f) the body of the request shall contain the RP-ACK or RP -ERROR message for the SM delivery report, as defined 
in 3GPPTS 24.011 [8]. 

NOTE 2: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in 
the body of the SIP MESSAGE request. 

5.3.2.5 Sending a notification about SM-over-IP receiver having memory available 

When an SM-over-IP receiver wants to send a notification about UE having memory available, the SM-over-IP receiver 
shall send a SIP MESSAGE request with the following information: 

a) the Request-URI, which shall contain the IP-SM-GW; 

NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity in the SIP MESSAGE request that 
included the short message the UE could not store. 

b) the From header, which shall contain a public user identity of the SM-over-IP receiver; 

c) the To header, which shall contain the IP-SM-GW; 

d) the Content-Type header shall contain "application/vnd.3gpp.sms"; and 

e) the body of the request shall contain an RP-SMMA message, see 3GPP TS 24.01 1 [8], including the SMS 
headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3]. 

NOTE 2: The SM-over-IP receiver will use content transfer encoding of type "binary" for the encoding of the SMS 
in the body of the SIP MESSAGE request. 
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5.3.3 IP-Short-Message-Gateway (IP-SM-GW) 

5.3.3.1 General 

An IP-SM-GW is an entity that provides the protocol interworking for the submission of short messages from the SM- 
over-IP sender to the SC, for the delivery of short messages from the SC to the SM-over-IP receiver, and for the SMS- 
Status Reports from the SC to the SM-over-IP sender. 

In addition to the procedures specified in subclause 5.3.3, the IP-SM-GW shall support the procedures specified in 
subclause 5.7 in 3GPP TS 24.229 [10]. 

5.3.3.2 Indication of SM-over-IP receiver availability status for delivery of short 
messages 

NOTE 1 : If operator policy does not require the indication the availability status of public user identity for receiving 
SMS over IP messages, then IP-SM-GW will not receive third-party REGISTER request. 

Upon receipt of a third-party REGISTER request, the IP-SM-GW shall: 

send a 200 (OK) response for the REGISTER request; 

if an MSISDN is received in the message body of the third party REGISTER request within the <service-info> 
XML element, store the MSISDN sent in the message body of the REGISTER request within the <service-info> 
XML element. 

- if no MSISDN is received, 

a) if an Authorization header field was contained in the REGISTER request received from the UE that is 
contained in a "message/sip" MIME body of the third party REGISTER request, derive the IMSI from the 
private user identity obtained from the "username" header field parameter of the Authorization header field 
in the REGISTER request received from the UE that is contained in a "message/sip" MIME body of the third 
party REGISTER request; or 

b) if no Authorization header field was contained in the REGISTER request received from the UE that is 
contained in a "message/sip" MIME body of the third party REGISTER request derive the IMSI from the 
public user identity obtained from the "To" header field in the REGISTER request received from the UE that 
is contained in a "message/sip" MIME body of the third party REGISTER request; and 

NOTE 2: The actual format of the <service-info> element is transparent to the S-CSCF. 

NOTE 3: The relation between private user identity and the IMSI is defined in 3GPP TS 23.003 [22]. 

NOTE 4: 3GPP TS 24.229 [10] specifies how the REGISTER request from the UE can be included in the third party 
REGISTER request. 

subscribe to the reg event package for the public user identity registered at the user's registrar (S-CSCF) as 
described in RFC 3680 [15]. 

Upon receipt of a NOTIFY request the IP-SM-GW shall check the availability status for receiving SMS over IP 
messages, i.e. if the public user identity has a contact registered with the ability to receive SMS over IP messages. If the 
availability status of the public user identity for receiving SMS over IP messages has changed, the IP-SM-GW shall 
start a data update procedure to the HSS as specified in 3GPP TS 29.002 [1 1] to indicate that either the MSISDN or 
IMSI registered with it is available/unavailable for delivery of SMS. 

5.3.3.3 Answering routing information query 

If a routing information query is received from the HSS/HLR, the IP-SM-GW shall extract the MSISDN of the SM- 
over-IP receiver (destination UE) from the received message. If the IP-SM-GW has information about a public user 
identity associated with the MSISDN, the IP-SM-GW shall return its own address to the SMS-GMSC that originated 
the routing information query. 

If the IP-SM-GW has no information related to the MSISDN of the SM-over-IP receiver (destination UE), the IP-SM- 
GW shall query the HSS/HLR for routing information. If the query results in an error response, the IP-SM-GW shall 
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return the error response to the SMS-GMSC; otherwise the IP-SM-GW shall return its own address to the SMS-GMSC 
that originated the routing information query. 

NOTE: The address of the SMS-GMSC is available in the received routing information query. 

5.3.3.4 Transport layer interworking 

5.3.3.4.1 Receiving a short message in a SIP MESSAGE request 

NOTE 1: The SIP MESSAGE received from the SM-over-IP sender/receiver will include a P-Asserted-Identity 
header (as defined in RFC 3325 [13]) containing a tel URI of the SM-over-IP sender/receiver and will 
contain either a short message (RP-DATA), or a notification for availability of memory (RP-SMMA), or 
a deUvery report (RP-ACK or RP-ERROR). 

If a SIP MESSAGE request including "vnd.3gpp.sms" payload is received from the SM-over-IP sender/receiver and the 
IP-SM-GW does not support the In-Reply-To header usage, the IP-SM-GW shall: 

1) respond with a 202 (Accepted) response; 

2) extract and validate the format of the SC address from the received payload as defined in 3GPP TS 24.01 1 [8] 
and 3GPPTS 23.040 [3]; 

3) extract the RPDU type (see 3GPP TS 24.01 1 [8]) from the received payload; 

4) add the MSISDN of the SM-over-IP receiver to the RP International Mobile Subscriber Identity field if the 
received payload is a notification for availability of memory. If the MSISDN of the SM-over-IP receiver is not 
available then insert the tel URI received in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in 
the SIP MESSAGE request by the P-CSCF or S-CSCF; and 

NOTE 2: The MSISDN is not available if the registration is not required according to the operator policy. 

5) include the RPDU type in the appropriate message to 

- the SC via SMS-IWMSC in case of a short message; 

the SC via SMS-GMSC in case of a delivery report; or 

the HSS in case of a notification for availability of memory. 

If step 2) or 3) above fails for message that contains RPDU with RP-DATA or RP-SMMA content, the IP-SM-GW 
shall send a SIP MESSAGE request with the following information: 

a) the Request-URI, containing the sending user"s URI; 

b) the Content-Type header, set to "application/vnd.3gpp.sms"; and 

c) the body of the request containing an RP-ERROR message including an appropriate error code as defined in 
3GPPTS 24.011 [8]. 

NOTE 3: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the 
body of the SIP MESSAGE request. 

If a SIP MESSAGE request including "vnd.3gpp.sms" payload is received from the sender/receiver, and the IP-SM-GW 
supports the In-Reply-To header, the IP-SM-GW shall: 

1) if the SIP MESSAGE does not include the In-Reply-To header: 

a) respond with a 202 (Accepted) response; 

b) extract and validate the format of the SC address from the received payload as defined in 
3GPP TS 24.011 [8] and 3GPP TS 23.040 [3]; 

c) extract the RPDU type (see 3GPP TS 24.01 1 [8]) from the received payload; 

d) the MSISDN of the SM-over-IP receiver to the RP International Mobile Subscriber Identity field if the 
received payload is a notification for availability of memory. If the MSISDN of the SM-over-IP receiver is 
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not available then insert the tel URI received in a P-Asserted-Identity header (as defined in RFC 3325 [13]) 
placed in the SIP MESSAGE request by the P-CSCF or S-CSCF; and 

NOTE 4: The MSISDN is not available if the registration is not required according to the operator policy. 

e) include the RPDU type in the appropriate message to 

- the SC via SMS-IWMSC in case of a short message; 

- the SC via SMS-GMSC in case of a delivery report; or 

the HSS in case of a notification for availability of memory. 

If step b) or c) above fails for message that contains RPDU with RP-DATA or RP-SMMA content, the IP-SM-GW 
shall send a SIP MESSAGE request with the following information: 

the Request-URI, containing the sending user"s URI; 

the Content-Type header, set to "application/vnd.3gpp.sms"; and 

the body of the request containing an RP -ERROR message including an appropriate error code as defined in 

3GPPTS 24.011 [8]. 

NOTE 5: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the 
body of the SIP MESSAGE request. 

2) if the SIP MESSAGE includes the In-Reply-To header: 

a) if the In-Reply-To header indicates that the request does not correspond to a short message submitted by the 
IP-SM-GW, send a 488 (Not Acceptable here) SIP response according to RFC 3428 [14]; 

b) if the In-Reply-To header indicates that the request corresponds to a short message submitted by the IP-SM- 
GW: 

generate a 202 (Accepted) SIP response according to RFC 3428 [14]; 

extract and validate the format of the SC address from the received payload as defined in 
3GPP TS 24.011 [8] and 3GPP TS 23.040 [3]; 

- extract the RPDU type (see 3GPP TS 24.01 1 [8]) from the received payload; 

- add the MSISDN of the SM-over-IP receiver to the RP International Mobile Subscriber Identity field if 
the received payload is a notification for availability of memory. If the MSISDN of the SM-over-IP 
receiver is not available then insert the tel URI received in a P-Asserted-Identity header (as defined in 
RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF; and 

NOTE 6: The MSISDN is not available if the registration is not required according to the operator policy. 

include the RPDU type in the appropriate message within the same MAP dialog delivering the short 

message to 

the SC via SMS-GMSC in case of a delivery report; or 

the HSS in case of a notification for availability of memory. 

NOTE 7: The IP-SM-GW finding the MAP dialog using the SIP session identified by the Call-ID contained in the 
In-Reply-To header. 

if step 2) or 3) above fails for message that contains RPDU with RP-SMMA content, the IP-SM-GW shall send a 
SIP MESSAGE request with the following information: 

the Request-URI, containing the sending user"s URI; 

the Content-Type header, set to "application/vnd.3gpp.sms"; and 

the body of the request containing an RP -ERROR message including an appropriate error code as defined 
in 3GPPTS 24.011 [8]. 
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NOTE 8: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the 
body of the SIP MESSAGE request. 

5.3.3.4.2 Delivering a short message in a SIP MESSAGE request 

If a short message is received from the SMS-GMSC, the IP-SM-GW shall extract the IMSI of the SM-over-IP receiver 
from the received message. Then the IP-SM-GW shall send a SIP MESSAGE request with the following information: 

a) the Request-URI, which shall contain a public user identity of the SM-over-IP receiver associated with the 
received IMSI; 

b) the Accept-Contact header, which shall contain a "H-g.3gpp.smsip" parameter and the "explicit" and "require" 
tags according to RFC 3841 [17]; 

c) the Request-Disposition header which shall contain the "no-fork" directive; 

d) the P-Asserted-Identity header which shall contain the SIP URI of the IP-SM-GW; 

e) the Content-Type header which shall contain "application/vnd.3gpp.sms"; and 

f) the body of the request which shall contain an RP-DATA message as defined in 3GPP TS 24.01 1 [8], including 
the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3]. 

NOTE 1 : The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the 
body of the SIP MESSAGE request. 

If the IP-SM-GW cannot deliver the short message successfully in a SIP MESSAGE request and cannot deliver the 
short message via SGSN or MSC, then the IP-SM-GW will apply the procedures defined in 3GPP TS 29.311 [23] 
subclause 6.1.4.4.1 to send a dehvery report to SC via SMS-GMSC. 

NOTE 2: If routing information is available (SGSN or MSC address or both), the IP-SM-GW can also attempt the 
delivery of a short message via SGSN or MSC or both before sending a delivery report to SC via SMS- 
GMSC. The priority order of these attempts (i.e., SMS over IP, SMS over CS, SMS over PS) is subject to 
operator policy. However, if no MSISDN is present in the short message then no routing information is 
obtainable by the IP-SM-GW, and attempting delivery of the short message via other domains (e.g. MSC, 
SGSN) by the IP-SM-GW is not possible. 

5.3.3.4.3 Forwarding a submit report in a SIP MESSAGE request 

If an SM submit report is received from the SMS-IWMSC, the IP-SM-GW shall retrieve the IMSI of the SM-over-IP 
sender from the existing MAP context. Then the IP-SM-GW shall obtain a corresponding public user identity and send 
a SIP MESSAGE request with the following information: 

a) the Request-URI, which shall contain a public user identity of the SM-over-IP sender; 

b) the Request-Disposition header which shall contain the "fork" and optionally the "parallel" directives; 

c) the In-Reply-To header which shall contain the Call-Id of the SIP MESSAGE request that included the 
submitted short message; 

d) the P-Asserted-Identity header which shall contain the SIP URI of the IP-SM-GW; 

e) the Content-Type header which shall contain "application/vnd.3gpp.sms"; and 

f) the body of the request which shall contain an RP-ACK or RP -ERROR message as defined in 
3GPPTS 24.011 [8]. 

NOTE: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the 
body of the SIP MESSAGE request. 

5.3.3.4.4 Delivering a status report in a SIP MESSAGE request 

If a status report is received from the SMS-GMSC, the IP-SM-GW shall extract the IMSI of the SM-over-IP sender 
from the received message. Then the IP-SM-GW shall send a SIP MESSAGE request with the following information: 
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a) the Request-URI, which shall contain a public user identity of the SM-over-IP sender associated with the 
received IMSI; 

b) the Accept-Contact header, which shall contain a "+g.3gpp.smsip" parameter and the "explicit" and "require" 
tags according to RFC 3841 [17]; 

c) the Request-Disposition header which shall contain the "no-fork" directive; 

NOTE 1 : The status report is always sent to the SMS capable UE that registered with the highest q value. 

d) the Content-Type header which shall contain "application/vnd.3gpp.sms"; and 

e) the body of the request which shall contain an RP-DATA message as defined in 3GPP TS 24.01 1 [8], including 
the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3]. 

NOTE 2: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the 
body of the SIP MESSAGE request. 

If the IP-SM-GW cannot deliver the status report successfully in a SIP MESSAGE request and cannot deliver the short 
message via SGSN or MSC, then the IP-SM-GW will apply the procedures defined in 3GPP TS 29.311 [23] 
subclause 6.1.4.4.1 to send a deHvery report to SC via SMS-GMSC. 

NOTE 3: If routing information is available (SGSN or MSC address or both), the IP-SM-GW can also attempt the 
delivery of a short message via SGSN or MSC or both before sending a delivery report to SC via SMS- 
GMSC. The priority order of these attempts (i.e., SMS over IP, SMS over CS, SMS over PS) is subject to 
operator policy. 

NOTE 4: The SM-over-IP sender will acknowledge the status report with a delivery report. 
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Annex A (normative): 

Media feature tags defined within the current document 

A.1 General 

This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN Subsystem for the 
realisation of SMS over IP. 

A.2 Definition of media feature tag g.Sgpp.smsip 

Media feature tag name: g.3gpp.smsip 

ASN.l Identifier: 1.3.6.1.8.2.3 

Summary of the media feature indicated by this tag: This feature-tag indicates that the device is capable of accepting 
SMS messages via SIP. 

Values appropriate for use with this media feature tag: Boolean. 

The media feature tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This media feature tag is most useful within SIP for noting the SMS capabilities of a device, such as a 
phone or PDA. 

Examples of typical use: Indicating that a mobile phone can receive short message encapsulated in a SIP MESSAGE 
request. 

Related standards or documents: 3GPP TS 24.341: "Support of SMS over IP networks, stage 3" 

Security Considerations: Security considerations for this media feature tag are discussed in subclause 11.1 of 
RFC 3840 [16]. 
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Annex B (informative): 

Example signalling flows of SMS over IP functionality 

B.1 Scope of signalling flows 

This annex gives examples of signalling flows for the SMS over IP within the IP Multimedia (IM) Core Network (CN) 
subsystem based on the Session Initiation Protocol (SIP) and SIP Events. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.204 [5]. 



B.2 Introduction 
B.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [9]. The following 
additional considerations apply: 

a) 3GPP TS 24.228 [9] shows separate signalling flows with no configuration hiding between networks, and with 
configuration hiding between networks. There is no SMS over IP specific functionality associated with this 
hiding, and therefore such separate signalling flows are not show in the present document; and 

b) 3GPP TS 24.228 [9] does not show the functionahty between the S-CSCF and the AS. As the SMS over IP 
functionality depends on the functionality provided by an AS, the signalling flows between S-CSCF and AS are 
shown in the present document. 

B.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [9] subclauses 4.1 and 4.2 applies with the additions 
specified below. 

ipsmgw.homel.net, ipsmgw.home2.net: IP-SM-GW in the home network of the SM-over-IP sender/receiver; 

- sc.homel.net: PSI of the SC of the SM-over-IP sender 

userl_publicl@homel.net: SM-over-IP sender; and 

user2_public2@home2.net: SM-over-IP receiver. 

As in 3GPP TS 24.228 [9], in order to differentiate between SIP methods and other protocol messages, the message 
name is preceded with the associated protocol for all non-SIP messages. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [9]. 

However, 3GPP TS 24.228 [9] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [9], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [9] in addition to the material 
shown in the present document. 
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B.3 Signalling flows demonstrating how IP-SM-GW 

indicates to HSS the availability of public user identity 
for delivery of short messages 



UE 



P-CSCF 



l-CSCF 



S-CSCF 



1. Successful UE registration 



T 



2. Evaluation 

of initial filter 

criteria 



HSS 



3. REGISTER 



200 OK 



IP-SM-GW 



5. SUBSCRIBE 



200 OK 



7. MOTIFY 



200 OK 



9. MAP:ATM 



10. MAP:ATM response 



Figure B.3-1 : IP-SM-GW registration signalling 

Figure B.3-1 shows the registration signalling flow for the scenario when IP-SM-GW registers to HSS. The details of 
the signalling flows are as follows: 

1. See 3GPP TS 24.228 [9], subclause 6.2 steps 1 through 22 

NOTE 1 : 3GPP TS 24.228 [9] contains Rel-5 registration; additional parameters might appear in Rel-7 registration. 

2. Initial filter criteria 

The S-CSCF analyses the incoming request against the initial filter criteria and decides to send a third-party 
REGISTER request to the IP-SM-GW. Initial Filter Criteria for IP-SM-GW includes a Service Information 
that contains the MSISDN belonging to "sip:userl_publicl@homel.net". 

3. REGISTER request (S-CSCF to IP-SM-GW) - see example in table B.3-1 

This signalHng flow forwards the REGISTER request from the S-CSCF to the IP-SM-GW. 

Table B.3-1 : REGISTER request (S-CSCF to IP-SM-GW) 



REGISTER sip: ipsmgw.homel .net SIP/2.0 
Via: SIP/2. 0/UDP sip: scscf 1 .homel .net 
Max-Forwards: 70 
P-Access-Network-Info : 
P-Visited-Network-ID : 
P-Charging-Vector : 
P-Charging-Function-Addresses : 
From: <sip:scscfl .homel .net>; tag=14142 
To: <sip :userl_publicl@homel .net> 
Contact: <sip : scscf 1 .homel .net> 
Expires: 60000 
Call -ID: apb0 3aOs0 9dkjdfglkj4 9112 
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CSeq: 43 REGISTER 

Content-Type : application/3gpp-ims+xml 

Content-Length: (...) 

<?xml version="l . 0" encoding="UTF-8" ?> 
<ims-3gpp version="l"> 

< service- info>llllllll</ service -info> 
</ims-3gpp> 



4. 200 OK response (IP-SM-GW to S-CSCF) - see example in table B.3-2 

The IP-SM-GW sends a 200 (OK) response to the S-CSCF indicating that registration was successful. 

Table B.3-2: 200 OK response (IP-SM-GW to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP sip : scscf 1 . homel . net 

From: 

To: 

Call-ID: 

Contact : <sip:scscfl .homel .net>;expires=600000 

CSeq: 

Date: Wed, 11 July 2001 08:49:37 GMT 

Content-Length : 



5. SUBSCRIBE request (IP-SM-GW to S-CSCF) - see example in table B.3-3 

The IP-SM-GW subscribes to the S-CSCF for the registration status of the registered subscriber. 

Table B.3-3 SUBSCRIBE request (IP-SM-GW to S-CSCF) 



SUBSCRIBE sip:userl_publicl@homel .net SIP/2.0 

Max-Forwards: 70 

Route : <sip:scscfl .homel .net ; lr> 

P-Asserted- Identity : <sip: ipsmgw. homel .net> 

P- Charging -Vector: icid-value="gwrg65hy35gw5hfrD46=583 735358" ; orig-ioi="type-3homel .net' 

P-Charging- Function-Addresses: ccf = [5555:c88:d7 7: :c66] ; ecf = [5555:c88:d7 7: :e67] 

From: <sip: ipsmgw. homel .net>; tag=3141528G 

To: <sip: scscf 1 .homel .net> 

Call-ID: 5 6uher6y5hrwy5wseg5y4w 

CSeq: 111 SUBSCRIBE 

Event : reg 

Expires: 600000 

Accept: application/reginf o+xml 

Contact: <sip: ipsmgw. homel .net> 

Content -Length: 



Request-URI: Public user identity whose registration status event the IP-SM-GW subscribes to. 
6. 200 (OK) response (S-CSCF to IP-SM-GW) - see example in table B.3-4 

The S-CSCF sends a 200 (OK) response to the IP-SM-GW. 

Table B.3-4: 200 (OK) response (S-CSCF to IP-SM-GW) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1. homel. net, •branch=z9hG4bK240tfe2 

P- Asserted- Identity: 

From: <sip: ipsmgw. homel .net>; tag=31415286 

To: <sip:scscfl .homel .net>; tag=1414 2 

Call-ID: 

CSeq: 

Contact : 

Expires : 

Content -Length: 



7. NOTIFY request (S-CSCF to IP-SM-GW) - see example in table B.3-5 
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The S-CSCF sends a first NOTIFY request to the IP-SM-GW. The notification indicates that the monitored 
public user identity registered using an SMS capable UE. 

Table B.3-5: NOTIFY request (S-CSCF to IP-SM-GW) 



NOTIFY sip: ipsmgw.homel .net SIP/2.0 

Max-Forwards: 70 

From: <sip:scscfl .homel .net>; tag=14142 

To: <sip: ipsmgw.homel .net>; tag=31415286 

Call-ID: 5 6uher6y5hrwy5wseg5y4w 

CSeq: 222 NOTIFY 

Subscription- State : active ;expires=GOOOOO 

Event : reg 

Content-Type : application/reginf o+xml 

Contact: <sip: scscfl .homel .net> 

Content -Length: (...) 

<?xml version="l . 0"?> 

<reginfo xmlns="urn: ietf :params :xml :ns : reginf o" version="l" state="full"> 

<registration aor="sip:userl_publicl@homel .net" id="a7" state="active"> 
<contact id="7G" state="active" event=" registered" > 
<uri>sip: [5555 : :aaa:bbb:ccc : ddd] </uri> 
<unknown-param name="+g. 3gpp. smsip"/> 
</contact> 
</registration> 
</reginf o> 



8. 200 (OK) response (IP-SM-GW to S-CSCF) - see example in table B.3-6 

IP-SM-GW sends a 200 (OK) response to the S-CSCF. 

Table B.3-6: 200 (OK) response (IP-SM-GW to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl .homel .net ;branch=z9hG4bK240tfe2 

From: 

To: 

Call-ID: 

CSeq: 

Content -Type : 

Content -Length: 



9. MAP: AnyTimeModification 

The IP-SM-GW sends the request to inform the HSS/HLR that the user with MSISDN " 1 11 1 1 1 11" is ready 
to receive short messages for delivery via IP via the sender of the request. 

For detailed message flows and coding see 3GPP TS 29.002 [11]. 

Table B.3-7 provides the parameters in the AnyTimeModification request, which are sent to the HSS/HLR. 

Table B.3-7: Data update procedure (IP-SM-GW to HSS/HLR) 



Message source 
and destination 


MAP Information element 
name 


Information 
source 


Description 


IP-SM-GW to 
HSS/HLR 


Subscriberldentity 


MSISDN in 

SIP 

REGISTER 

request 


This information element indicates the 
MSISDN of the subscriber 


IP-SM-GW to 
HSS/HLR 


gsmSCF-Address 


(static) IP-SM- 
GW 


HSS/HLR should forward messages 
related to SM delivery to this address 


IP-SM-GW to 
HSS/HLR 


modifyRegistrationStatus of 

the modificationRequestFor- 

SM-GW-Data 


(static) IP-SM- 
GW 


This information element indicates the 
registration status (activate) towards 
HSS/HLR 



10. MAP: AnyTimeModification response 
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The HSS/HLR acknowledges the request. 

NOTE 2: The positive ATM response (Resuh message) does not contain any resuh code, negative response (Error 
message) contains an error code. 



B.4 Signalling flows demonstrating how IP-SM-GW 

indicates to HSS the unavailability of UE for delivery 
of short messages 
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Figure B.4-1 : IP-SM-GW deregistration signalling 

Figure B.4-1 shows the registration signalling flow for the scenario when IP-SM-GW deregisters to HSS. The details of 
the signalling flows are as follows: 

1. See 3GPP TS 24.228 [9], subclause 6.2 steps 1 through 22 

Expires header set to zero. Public user identity deregisters its last SMS capable contact. 

NOTE 1: A flow for deregistration is not provided in 3GPP TS 24.228 [9]. However, deregistration is similar to a 
registration with the Expires header set to zero. Compared to a Rel-5 deregistration additional parameters 
might appear in a later release. 

2. NOTIFY request (S-CSCF to IP-SM-GW) - see example in table B.4-1 

The S-CSCF sends a first NOTIFY request to the IP-SM-GW. The notification indicates that the monitored 
public user identity is not registered any more with an SMS capable UE. 
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Table B.4-1 : NOTIFY request (S-CSCF to IP-SM-GW) 



NOTIFY sip: ipsmgw.homel .net SIP/2.0 

Max-Forwards: 70 

From: <sip:scscfl .homel .net>; tag=14142 

To: <sip: ipsmgw.homel .net>; tag=31415286 

Call-ID: 5 6uher6y5hrwy5wseg5y4w 

CSeq: 222 NOTIFY 

Subscription-State : active ; expires=234546 

Event : reg 

Content-Type : application/reginf o+xml 

Contact: <sip: scscfl .homel .net> 

Content -Length: (...) 

<?xml version="l . 0"?> 

<reginfo xmlns="urn: ietf :params :xml :ns : reginf o" version="l" state="full"> 

<registration aor="sip:userl_publicl(ahomel .net " id="a7" state="terminated"> 
<contact id="77" state="terminated" event="unregistered"> 

<uri>sip: [5555 : :aaa:bbb: ccc :ddd] </uri> 
</contact> 
</registration> 

<registration aor="sip:userl_public2@homel .net " id="a8" state="active"> 
<contact id="77" state="active" event="registered"> 

<uri>sip: [5555 : :aaa:bbb: ccc :eee] </uri> 
</contact> 
</registration> 
</reginf o> 



3. 200 (OK) response (IP-SM-GW to S-CSCF) - see example in table B.4-2 

IP-SM-GW sends a 200 (OK) response to the S-CSCF. 

Table B.4-2: 200 (OK) response (IP-SM-GW to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl .homel .net ;branch=z9hG4bK240tfe2 

From: 

To: 

Call-ID: 

CSeq: 

Cont ent - Type : 

Content -Length: 



4. MAP: AnyTimeModification 

The IP-SM-GW sends the request to inform the HSS/HLR that the user with MSISDN " 1 1 1 11 1 1 1 " is not 
available to receive short messages for delivery via IP via the sender of the request. 

For detailed message flows and coding see 3GPP TS 29.002 [11]. 

Table B.4-3 provides the parameters in the AnyTimeModification request, which are sent to the HSS/HLR. 

Table B.4-3: MAP: AnyTimeModification request (IP-SM-GW to HSS/HLR) 



Message source 
and destination 


MAP Information element 
name 


Information 
source 


Description 


IP-SM-GW to 
HSS/HLR 


Subscriberldentity 


MSISDN in 

SIP 

REGISTER 

request 


This information element Indicates tine 
MSISDN of the subscriber 


IP-SM-GW to 
HSS/HLR 


gsmSCF-Address 


(static) IP-SM- 
GW 


HSS/HLR should forward messages 
related to SM delivery to this address 


IP-SM-GW to 
HSS/HLR 


modifyRegistrationStatus of 

the modificationRequestFor- 

SM-GW-Data 


(static) IP-SM- 
GW 


This information element indicates the 
registration status (deactivate) 
towards HSS/HLR. 



MAP: AnyTimeModification response 
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The HSS/HLR acknowledges the request. 

NOTE 2: The positive ATM response (Resuh message) does not contain any result code; negative response (Error 
message) contains an error code. 



B.5 Signalling flows demonstrating successful UE 
originated SM submit procedure over IP 



UE 



P-CSCF 



1. MESSAGE 



S. 202 Acceptecp 



7. 202 Accepte(J 



11. MESSAGE 



12. 200 OK 



S-CSCF 



2. MESSAGE 



IP-SM-GW 



3. Evaluate 
iFC 



5. 202 Accepte(J 



10. MESSAGE 



13. 200 OK 



4. MESSAGE 



8. Extract and 

forward SM, 

receive report 



9. MESSAGE 



14. 200 OK 



Figure B.5-1 : UE originated SIU! submit procedure over IP signalling 

Figure B.5-1 shows a successful UE originated SM over IP submission. For simplicity it is assumed that IP-SM-GW 
has direct access to SC. The details of the signalling flows are as follows: 

1. MESSAGE request (UE to P-CSCF) - see example in table B.5-1 

This request includes a vnd.3gpp.sms payload that includes the short message and routing information for the 
IP-SM-GW to forward the short message. 

Table B.5-1 : MESSAGE request (UE to P-CSCF) 



MESSAGE sip: SC .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357;comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <sip : SC .homel .net .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 666 MESSAGE 

Content-Type : application/vnd . 3gpp . sms 

Content-Length: (...) 
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Request-URI: PSI of the SC ofuserl_publicl@homel.net. 
The payload includes an RP-DATA message (see 3GPP TS 24.011 [8]). It includes: 
Address of the originating UE: this field includes the length indicator only; 
Address of the destination SC, which is configured in the UE; and 
- RP-User-Data (see 3GPP TS 23.040 [3]), which includes SMS-SUBMIT as type indicator. 
2. MESSAGE request (P-CSCF to S-CSCF) - see example in table B.5-2 

Table B.5-2: MESSAGE request (P-CSCF to S-CSCF) 



MESSAGE sip: SC .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 341 , SIP/2. 0/UDP 

[5555: : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip : origSscscf 1 . homel . net ; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl®homel .net> 
From: <sip :userl_publicl@homel .net>; tag=171828 
To: <sip : SC .homel .net> 
Call -ID: Cb03a0s0 9a2sdfglkj 490333 
Cseq: 666 MESSAGE 

Content-Type : application/vnd . 3gpp . sms 
Content-Length: (...) 



3. Initial filter criteria 

The S-CSCF analyses the incoming request against the initial filter criteria and decides to send the SIP 
MESSAGE request to the IP-SM-GW. 

4. MESSAGE request (S-CSCF to IP-SM-GW) - see example in table B.5-3 

Table B.5-3: MESSAGE request (S-CSCF to IP-SM-GW) 



MESSAGE sip: sc.homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscfl. homel. net;branch=z9hG4bK344a651, SIP/2 . 0/UDP 
pcscf 1. visitedl. net ;branch=z9hG4bK24 Of 341, SIP/2 .0/UDP 
[5555: : aaa :bbb: CCC :ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : <sip : ipsmgw. homel .net; lr>, <sip : Cb03a0s0 9a2sdfglkj490333@scscf 1 .homel .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P- Asserted- Identity: tel : +1212 5551111 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <sip : SC. homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 666 MESSAGE 

Content-Type : application/vnd . 3gpp . sms 

Content-Length: (...) 



5. 202 (Accepted) response (IP-SM-GW to S-CSCF) - see example in table B.5-4 

Table B.5-4: 202 (Accepted) response (IP-SM-GW to S-CSCF) 



SIP/: 


.0 202 


Accepted 


















via: 


SIP/2. 


0/UDP scscfl 


homel 


.net 


;branch= 


z9hG4bK344a651, SIP/2 


0/UDP 




pcscf 1 


.visitedl 


net ;branch=z 


9hG4bK240f341, 


SIP/2. 


0/UDP 






[5555: 


: aaa :bbb : ccc 


ddd] : 


1357 


; comp= s igcomp ; 


brancl- 


=z9hG4bKnashds7 


From 






















To: 






















Call- 


ID: 




















Cseq 
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6. 202 (Accepted) response (S-CSCF to P-CSCF) - see example in table B.5-5 

Table B.5-5: 202 (Accepted) response (S-CSCF to P-CSCF) 



SIP/2 


.0 202 


Accepted 




















Via: 


SIP/2. 


0/UDP pcscfl 


visi 


tedl. 


net 


-branch=z9hG4bK24 0f341, 


SIP/2 


.0/UDP 




[5555: 


: aaa :bbb : ccc 


ddd] 


:1357 


; comp= 


=sigcomp; 


branch= 


z9hG4bKnas 


hds7 


From: 
























To: 
























Call- 


ID: 






















Cseq: 

























7. 202 (Accepted) response (P-CSCF to UE) - see example in table B.5-6 

Table B.5-6: 202 (Accepted) response (P-CSCF to UE) 



SIP/2.0 202 Accepted 








Via: SIP/2. 0/UDP [5555: 


: aaa : bbb : ccc : ddd] 


: 13 5 7;comp=sigcomp; 


branch=z9hG4bKnashds7 


From: 








To: 








Call-ID: 








Cseq: 









8. Extracting and forwarding the short message, waiting and processing report 

The IP-SM-GW forwards the short message TPDU (SMS-SUBMIT) to the SC. The SC returns a submit 
report which includes SMS-SUB MIT-REPORT as type indicator. 

9. MESSAGE request (IP-SM-GW to S-CSCF) - see example in table B.5-7 

This request includes a vnd.3gpp.sms payload that includes the short message submission report and routing 
information for the IP-SM-GW to forward the submission report. 

Table B.5-7: MESSAGE request (IP-SM-GW to S-CSCF) 



MESSAGE sip: userl_publicl@homel.net SIP/2.0 

Via: SIP/2. 0/UDP ipsmgw.homel.net; branch=z9hG4bK876f f a3 

Max- Forwards : 70 

Route : <sip : scscf 1 . homel . net ; lr> 

From: <sip : ipsmgw. homel .net>; tag=583558 

To : <sip : userl_publicl®homel . net> 

Call -ID: fy3 65h43g3f36f3f6fth74g3 

Cseq: 888 MESSAGE 

P-Asserted- Identity : <sip : ipsmgw. homel .net> 

In-Reply-to: cb03a0s0 9a2sdfglkj 4 90333 

Request-Disposition : fork, parallel 

Content-Type : application/vnd . 3gpp . sms 

Content-Length: (...) 



Request-URI: Public user identity receiving the submission report. 

The payload includes an RP-ACK message (see 3GPP TS 24.01 1 [8]). It includes RP-User-Data (see 
3GPP TS 23.040 [3]), which includes SMS-SUBMIT-REPORT as type indicator. 

10. MESSAGE request (S-CSCF to P-CSCF) - see example in table B.5-8 

Table B.5-8: MESSAGE request (S-CSCF to P-CSCF) 



MESSAGE sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1. homel. net;branch=z9hG4bK344a651, SIP/2. 0/UDP ipsmgw.homel.net; 

branch=z9hG4bK8 76ffa3 
Max-Forwards: 69 

Route : <sip : pcscfl . visitedl .net : 7531; lr;comp=sigcomp> 
From: <sip : ipsmgw. homel .net>; tag=583558 
To : <sip : userl_publicl@homel . net> 
Call -ID: fy365h43g3f36f3f6fth74g3 
Cseq: 888 MESSAGE 
P-Asserted- Identity : <sip : ipsmgw. homel .net> 
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P- Called- Party- ID: <sip :userl_publicl@homel .net> 
In-Reply-to: cb03aOs09a2sdfglkj 490333 
Request -Disposition: fork, parallel 
Content-Type : application/vnd . 3gpp . sms 
Content-Length: (...) 



1 1. MESSAGE request (P-CSCF to UE) - see example in table B.5-9 

Table B.5-9: MESSAGE request (P-CSCF to UE) 



MESSAGE sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK2524fd2, SIP/2. 0/UDP 

scscf 1 .homel .net;branch=z9hG4bK344a651, SIP/2. 0/UDP ipsmgw.homel.net; branch=z9hG4bK876f f a3 
Max-Forwards: 68 

From: <sip : ipsmgw. homel .net>; tag=583558 
To : <sip :userl_publicl@homel .net> 
Call -ID: fy365h43g3f36f3f6fth74g3 
Cseq: 888 MESSAGE 

P- Called- Party- ID : <sip :userl_publicl@homel .net> 
In-Reply-to: Cb03a0s09a2sdfglkj 490333 
Request-Disposition : fork, parallel 
Content-Type : application/vnd . 3gpp . sms 
Content-Length: (...) 



12. 200 (OK) response (IP-SM-GW to S-CSCF) - see example in table B.5-10 

Table B.5-10: 200 (OK) response (UE to P-S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK2524f d2 , SIP/2. 0/UDP 

scscf 1. homel. net, •branch=z9hG4bK344a651, SIP/2. 0/UDP ipsmgw.homel.net; branch=z9hG4bK876f f a3 
From: 
To: 

Call-ID: 
Cseq: 



13. 200 (OK) response (P-CSCF to S-CSCF) - see example in table B.5-11 

Table B.5-11 : 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK344aS51 , 


SIP/2. 0/UDP ipsmgw.homel.net; 


branch=z9hG4bK8 76ffa3 




From: 




To: 




Call-ID: 




Cseq: 





14. 200 (OK) response (S-CSCF to IP-SM-GW) - see example in table B.5-12 

Table B.5-12: 200 (OK) response (S-CSCF to IP-SM-GW) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP ipsmgw.homel.net; 


branch=z9hG4bK876ffa3 


From: 




To: 




Call-ID: 




Cseq: 
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B.6 Signalling flows demonstrating successful UE 

terminated SM deliver procedure over IP (including 
delivery report) 



UE 




P-CSCF 




S-CSCF 




IP-SM-GW 




















1 




4. MESSAGE 


3. MESSAGE 




1 . Receive 
SM 




2. MESSAGE 






7. 200 OK 






6. 200 OK 






5. 200 OK 






8. MESSAGE 






9. MESSAGE 
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10. Evaluate 
iFG 












11. MESSAGE 






3. 202 Accepte 


2. 202 Accepte 
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1 5 Forward 
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■^ 1 


d 








report 

1 



Figure B.6-1 : UE originated SIUI deliver procedure over IP signalling 

It is assumed that "sip:user2_public2@home2.net" associated with MSISDN=1 1 111111 is registered at 
ipsmgw.home2.net using an SMS capable UE. 

Figure B.6-1 shows a successful UE terminated SM over IP delivery. The details of the signalling flows are as follows: 

1. Receiving SM from SC 

The IP-SM-GW receives a short message from SC (sc.homel.net) which includes SMS-DELIVER as type 
indicator and MS1SDN=1 1 1 1 1 1 1 1 as destination UE. 

2. MESSAGE request (IP-SM-GW to S-CSCF) - see example in table B.6-1 

This request includes a vnd.3gpp.sms payload that includes the short message and routing information for the 
S-CSCF to forward the short message. 

Table B.6-1 : MESSAGE request (IP-SM-GW to S-CSCF) 



MESSAGE sip:user2_public2®home2 .net SIP/2.0 

Via: SIP/2. 0/UDP ipsmgw.home2.net; branch=z9hG4bK876f f a3 

Max- Forwards : 70 

Route : <sip : scscf 1 . home2 . net ; lr> 

From: <sip : ipsmgw.home2 .net>; tag=583558 

To : <sip : user2_public2®home2 . net> 

Call -ID: fy3 65h43g3f36f3f6fth74g3 

Cseq: 888 MESSAGE 

P-Asserted- Identity : sip : ipsmgw.home2 .net 

Request-Disposition: no-fork 

Accept -Contact : * ; +g. 3gpp . smsip; require /explicit 

Content-Type : application/vnd . 3gpp . sms 

Content-Length: (...) 
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Request-URI: Public user identity receiving the delivery report. 

The payload includes the RP-DATA message (see 3GPP TS 24.01 1 [8]). Its RP-User-Data information element 
includes a TPDU of type SMS-DELIVER. 

3. MESSAGE request (S-CSCF to P-CSCF) - see example in table B.6-2 

S-CSCF performs the caller preferences to callee capabilities matching and builds the Request-URI with the 
selected contact. 

Table B.6-2: MESSAGE request (S-CSCF to P-CSCF) 



MESSAGE sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK344a651, SIP/2. 0/UDP ipsmgw.home2.net; 

branch=z9hG4bK876ffa3 
Max-Forwards: 69 

Route : <sip :pcscf 2 . visited2 .net : 75 31; lr;comp=sigcomp> 
From: <sip : ipsmgw.home2 .net>; tag=583558 
To : <sip : user2_public2®home2 . net> 
Call -ID: fy3 65h43g3f3 6f3f6fth74g3 
Cseq: 888 MESSAGE 

P-Asserted- Identity : sip : ipsmgw.home2 .net 
P- Called- Party- ID: <sip :user2_public2@home2 .net> 
Request-Disposition: no-fork 

Accept -Contact : * ; +g. 3gpp . smsip; require; explicit 
Content-Type : application/vnd . 3gpp . sms 
Content-Length: (...) 



Request-URI: SMS capable contact of the public user identity. 

4. MESSAGE request (P-CSCF to UE) - see example in table B.6-3 

Table B.6-3: MESSAGE request (P-CSCF to UE) 



MESSAGE sip: [5555 : :aaa:bbb:CCC:ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net;branch=z9hG4bK2524fd2, SIP/2. 0/UDP 

scscf2 .home2 .net;branch=z9hG4bK344aS51, SIP/2. 0/UDP ipsmgw.home2.net; branch=z9hG4bK876f f a3 
Max- Forwards : 6 8 

From: <sip : ipsmgw.home2 .net>; tag=583558 
To : <sip : user2_public2@home2 . net> 
Call -ID: fy365h43g3f36f3f6fth74g3 
Cseq: 888 MESSAGE 

P- Called- Party- ID : <sip :user2_public2®home2 .net> 
Request-Disposition: no-fork 

Accept -Contact : * ; +g. 3gpp . smsip; require; explicit 
Content-Type : application/vnd . 3gpp . sms 
Content-Length: (...) 



5. 200 (OK) response (UE to P-CSCF) - see example in table B.6-4 

Table B.6-4: 200 (OK) response (UE to P-S-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf2.visited2.net;branch=z9hG4bK2524fd2, SIP/2. 0/UDP 




scscf2 .home2 .net ;branch=z9hG4bK344a651, SIP/2 . 0/UDP ipsmgw.home2 .net; 


branch=z9hG4bK8 76ffa3 


From: 




To: 




Call-ID: 




Cseq: 
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6. 200 (OK) response (P-CSCF to S-CSCF) - see example in table B.6-5 

Table B.6-5: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP scscf2.home2.net;branch=z9hG4bK344a651, 


SIP/2. 0/UDP ipsmgw.home2.net; 


branch=z9hG4bK876ffa3 




From: 




To: 




Call-ID: 




Cseq: 





7. 200 (OK) response (S-CSCF to IP-SM-GW) - see example in table B.6-6 

Table B.6-6: 200 (OK) response (S-CSCF to IP-SM-GW) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP ipsmgw.home2.net; 


branch=z9hG4bK8 76ffa3 


From: 




To: 




Call-ID: 




Cseq: 





8. MESSAGE request (UE to P-CSCF) - see example in table B.6-7 

This request includes a vnd.3gpp.sms payload that includes the SMS -DELI VER-REPORT and routing 
information for the IP-SM-GW to forward the delivery report. 

Table B.6-7: MESSAGE request (UE to P-CSCF) 



MESSAGE sip: ipsmgw.home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357;comp=sigcomp; branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route: <sip :pcscf 2 . visited2 .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 2 .home2 .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip:user2_public2®home2 .net> 

From: <sip :user2_public2@home2 .net>; tag=171828 

To: <sip : ipsmgw.home2 .net> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 903 3 3 

In-Reply-to: fy365h43g3f 36f 3f 6f th74g3 

Cseq: 999 MESSAGE 

Content-Type : application/vnd . 3gpp . sms 

Content-Length: (...) 



Request-URI: The IP-SM-GW that sent the SIP MESSAGE request including the delivered short message to the 
SM-over-IP receiver. 

The payload includes an RP-ACK message (see 3GPP TS 24.01 1 [8]). Its RP-User-Data information element 
includes a TPDU of type SMS-DELIVER-REPORT. 

9. MESSAGE request (P-CSCF to S-CSCF) - see example in table B.6-8 

Table B.6-8: MESSAGE request (P-CSCF to S-CSCF) 



MESSAGE sip: ipsmgw.home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK240f 341 , SIP/2. 0/UDP 

[5555: : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp; branch=z9hG4bKnashds7 
Max- Forwards : 6 9 

Route : <sip : origOscscf 2 . home2 . net ; lr> 

P-Asserted-Identity : "John Doe" <sip :user2_public2@homel .net> 
From: <sip :user2_public2@home2 .net>; tag=171828 
To: <sip : ipsmgw.home2 .net> 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
In-Reply-to: fy365h43g3f 3 6f 3f 6f th74g3 
Cseq: 999 MESSAGE 

Content-Type : application/vnd . 3gpp . sms 
Content-Length: (...) 
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10. Initial filter criteria 

The S-CSCF analyses the incoming request against the initial filter criteria and decides to send the SIP 
MESSAGE request to the IP-SM-GW. 

1 1. MESSAGE request (S-CSCF to IP-SM-GW) - see example in table B.6-9 

Table B.6-9: MESSAGE request (S-CSCF to IP-SM-GW) 



MESSAGE sip: ipsmgw.home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK344a651, SIP/2. 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK240f 341, SIP/2 . 0/UDP 
[5555: :aaa:bbb : ccc :ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : <sip : ipsmgw.home2 .net; lr>, <sip : Cb03a0s09a2sdfglkj49033 3®scscf 2 .home2 .net; lr> 

P-Asserted-Identity : "John Doe" <sip :user2_public2@home2 .net> 

P-Asserted- Identity: tel : +1212 5552222 

From: <sip :user2_public2@home2 .net>; tag=171828 

To: <sip : ipsmgw.home2 .net> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

In-Reply-tO: fy365h43g3f 36f 3f 6f th74g3 

Cseq: 666 MESSAGE 

Content-Type : application/vnd . 3gpp . sms 

Content-Length: (...) 



12. 202 (Accepted) response (IP-SM-GW to S-CSCF) - see example in table B.6-10 

Table B.6-10: 202 (Accepted) response (IP-SM-GW to S-CSCF) 



SIP/2 


.0 202 


Accepted 


















Via: 


SIP/2. 


0/UDP scscf2 


home 2 


.net 


;branch= 


z9hG4bK344a651, SIP/2 


0/UDP 




pcscf 2 


. visited2 


net ;branch=z 


9hG4bK240f341, 


SIP/2. 0/UDP 






[5555: 


: aaa :bbb : ccc 


ddd] : 


1357 


;comp=sigcomp; 


branch= 


=z9hG4bKnashds7 


From 






















To: 






















Call- 


ID: 




















Cseq 























13. 202 (Accepted) response (S-CSCF to P-CSCF) - see example in table B.6-11 

Table B.6-1 1 : 202 (Accepted) response (S-CSCF to P-CSCF) 



SIP/2 


.0 202 


Accepted 




















Via: 


SIP/2. 


0/UDP pcscf2 


visi 


ted2. 


net 


-branch=z9hG4bK24 0f341, 


SIP/2 


.0/UDP 




[5555: 


: aaa :bbb : ccc 


ddd] 


:1357 


; comp= 


=sigcomp; 


branch= 


z9hG4bKnas 


hds7 


From: 
























To: 
























Call- 


ID: 






















Cseq: 

























14. 202 (Accepted) response (P-CSCF to UE) - see example in table B.6-12 

Table B.6-12: 202 (Accepted) response (P-CSCF to UE) 



SIP/2.0 202 Accepted 








Via: SIP/2. 0/UDP [5555: 


: aaa : bbb : ccc : ddd] 


: 1357;comp=sigcomp; 


branch=z9hG4bKnashds7 


From: 








To: 








Call-ID: 








Cseq: 









15. Extracting and forwarding the delivery report 

The IP-SM-GW forwards the short message TPDU (SMS-DELIVER-REPORT) to the SC. 



£75/ 



3GPP TS 24.341 version 11.2.0 Release 11 



32 



ETSI TS 124 341 V1 1.2.0 (2013-01) 



Annex C (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


2006-05 










Initial version 






2006-05 










Version 0.1 .0 incorporating results of CT1 discussions at CT1 #42. 
Agreed documents: CI -061 049 (revised TS skeleton), CI -061 050, 
CI -061 052, CI -061 053, and CI -061 067. 






2006-07 










Version 0.2.0 incorporating results of CT1 discussions at CT1 
#42bis. Agreed documents: CI -061 1 40, CI -061 329, CI -061 330, 
C1-061333, C1-061334, C1-061335, C1-061353, C1-061354, C1- 
061359, and CI -061 360. 






2006-09 










Version 0.3.0 incorporating results of CT1 discussions at CT1 #43. 
Agreed documents: CI -061 429, CI -061 431, CI -061 546, C1- 
061567, CI -061 635, CI -061 787, CI -061 788, CI -061 789, C1- 
061790, and CI -061 791. 


0.2.0 


0.3.0 


2006-11 










Version 0.4.0 incorporating results of CT1 discussions at CT1 #44. 
Agreed documents: CI -062055, CI -0621 82, CI -06221 8, C1- 
06???4, CI -062384, CI -062385, CI -062386, CI -062387, C1- 
062388, CI -062389, CI -062391, and CI -062432. 


0.3.0 


0.4.0 


2006-11 










Version 1 .0.0 created by MCC for presentation of thie TS to TSG 


0.4.0 


1.0.0 


2007-02 










Version 1 .1 .0 incorporating results of CT1 discussions at CT1 #45. 
Agreed documents: CI -070331, CI -070334, CI -070335, C1- 
070338, CI -070543, CI -070545, CI -070546, and CI -070637. 


1.0.0 


1.1.0 


2007-02 










Version 2.0.0 created by MCC 


1.1.0 


2.0.0 


2007-03 










Version 7.0.0 created by MCC 


2.0.0 


7.0.0 


2007-06 


CT#36 


CP-070384 


0017 


1 


Adding status report procedure, forl<ing related corrections plus 
editorial changes 


7.0.0 


7.1.0 


2007-06 


CT#36 


CP-070384 


0015 


1 


P-Asserted-ldentity corrections 


7.0.0 


7.1.0 


2007-06 


CT#36 


CP-070384 


0010 


1 


IP-SM-GW as Request-URI for delivery report 


7.0.0 


7.1.0 


2007-06 


CT#36 


CP-070384 


0008 


1 


SC as Request-URI for sfiort message submit 


7.0.0 


7.1.0 


2007-06 


CT#36 


CP-070384 


0005 


- 


Correction of text on media feature tag g.3gpp.smsip 


7.0.0 


7.1.0 


2007-06 


CT#36 


CP-070384 


0002 


1 


Corrections to example flows 


7.0.0 


7.1.0 


2007-12 


CT#38 


CP-070801 


0018 




Feature tag for SMSIP registered by lANA 


7.1.0 


7.2.0 


2007-12 


CT#38 


CP-070801 


0019 


1 


Miscellaneous corrections 


7.1.0 


7.2.0 


2008-12 


CT#42 








Upgrade to Rel-8 


7.2.0 


8.0.0 


2009-03 


CT#43 


CP-090122 


0022 


1 


SRI4SM handling in IP-SM-GW 


8.0.0 


8.1.0 


2009-09 


CT#45 


CP-090655 


0024 


2 


Support of operator preference for domain selection of SMS 


8.1.0 


8.2.0 


2009-12 


CT#46 


CP-090897 


0028 


1 


Correction to 'Submitting a short message' for a SM-over-IP sender 


8.2.0 


8.3.0 


2009-12 


CT#46 


CP-090923 


0026 


1 


SM termination and deregistration corrections 


8.3.0 


9.0.0 


2010-06 


CT#48 


CP-1 00338 


0032 


2 


Resolving EN 


9.0.0 


9.1.0 


2010-12 


CT#50 


CP-1 00741 


0034 


8 


Obtaining the PSI of the SC 


9.1.0 


9.2.0 


2011-03 


CT#51 








Upgrade to Rel-10 


9.2.0 


10.0.0 


2011-09 


CT#53 


CP-1 10694 


0035 


1 


Correcting errors in the B.5 example 


10.0.0 


11.0.0 


2012-06 


CT#56 


CP-1 20307 


0041 




IP-SM-GW registration/de-registration 


11.0.0 


11.1.0 


2012-06 


CT#56 


CP-1 20307 


0042 


2 


Correlation of SIP MESSAGE in UE terminated SM deliver 
procedure over IP 


11.0.0 


11.1.0 


2012-12 


CT#58 


CP-1 20803 


0043 


3 


Terminating SMS to MSISDNIess UE 


11.1.0 


11.2.0 


2012-12 


CT#58 


CP-1 20793 


0044 


1 


User error parameter in delivery report to SC 


11.1.0 


11.2.0 



£75/ 



3GPP TS 24.341 version 11.2.0 Release 11 



33 



ETSI TS 124 341 V1 1.2.0 (2013-01) 



History 



Document history 


Vll.l.O 


November 2012 


Publication 


VI 1.2.0 


January 2013 


Publication 





















£75/ 



